@adanot and @gbrcmg does this fix work for you too? Install with:

npm i -g T-Tmnr/serverless-python-requirements#fix-issue-274

@heri16 @kichik, does this look good?

I'm not sure how that would work based on this comment:

#274 (comment)

With quotes on bindPath itself it will produce commands with:

-v something:"something with space"

But the comment suggests (and it seems logically correct) this is required:

-v "something:something with space"

@kichik, does the inclusion of windowsVerbatimArguments not affect this choice?

I think it just tells it not to convert -v test:"hello world" to -v "test:"hello world"".

I modified code using modification on v4.2.5 fully.

@kichik -v "something:something with space" is also correct.
I try to fix the issue by this pattern on my another branch.
https://github.com/T-Tmnr/serverless-python-requirements/tree/fix-issue-274-another
But it's revert changes at dockerPathForWin of v4.2.5.

windowsVerbatimArguments option tells 'not quoating cmdOptions on windows platform'.
In this case cmdOptions=['-v', 'test:"hello world"'] without windowsVerbatimArguments,
quating 'test:"hello world"' to '"test:"hello world""'.
Finally, the spawned command got arguments bellow.

$1=-v 
$2="test:\"hello 
$3=world\"" 

I posted to the issue.
#274 (comment)

My two cents on this:

1. -v "something:something with spaces" is more correct than -v something:"something with space" and doesn't rely on any special treatment of quotes.
2. It will be easier in the future if we separate quote handling from command generation. We might have more code paths that we're missing here or that will be added. I personally prefer letting the code doing the actual execution deal with the quoting. In this case it would be spawnSync() without windowsVerbatimArguments. If it doesn't know how to properly quote, let's create a wrapper for it that does. But handling the quotes in the code that builds the command will mean that has to be done in any code that calls a command.

It will be easier in the future if we separate quote handling from command generation.

I'm doing exactly that in #292 for exactly the reason you mentioned.